|
|
|
|
|
|
|
your actual core domain classes, so you have to rely on beta tests of both the application and the user guides to indirectly verify the goodness of your classes. However, with your user guides, you can describe your domain classes as key concepts and possibly query your users whether these key concepts are well-defined. |
|
|
|
|
|
|
|
|
Having other project members and project teams use your classes. Reuse over time is the single best way of determining whether your classes are well designed. |
|
|
|
|
|
|
|
|
If you're heading up a team of developers, try not to be too hard on yourself if any of these project state factors are negative. Problems will occur and mistakes will happen. Use the results of the assessment, instead, to encourage better development habits and to come up with a strategy for correcting any problems. |
|
|
|
|
|
|
|
|
Documenting the Expected Response of the System |
|
|
|
|
|
|
|
|
Refining your use cases throughout the life of your project is important for the system's accuracy in responding to user stimuli. Use cases give life to otherwise static requirements typical of many projects. |
|
|
|
|
|
|
|
|
Not all use cases should have the same priorities. That means that when a deadline is fast approaching and you need to cut back on revisiting some use cases, you should try to revisit the core use cases. Core use cases are the ones that you want in your first (and, if necessary, second) iteration. If you can't meaningfully revisit most of your core use cases, your project is in jeopardy of being rejected by users during user acceptance testing. |
|
|
|
|
|
|
|
|
Use cases also have implications for performance. The implementation of a use case in code must conform to performance expectations. Therefore, performance requirements need to be reassessed and tracked in a separate but linked file. |
|
|
|
|
|
|
|
|
Preserving the Artifacts of Use-Case Analysis and Development in General |
|
|
|
|
|
|
|
|
As you iterate through the development of your application, you will have to refine your artifacts. Such artifacts include |
|
|
|
|
|
|
|
|
User requirements, which are realized in a use-case model (and associated performance requirements) |
|
|
|
|
|
|
|
|
Interaction diagrams such as sequence and collaboration diagrams |
|
|
|
|
|
|
|
|
State and activity diagrams |
|
|
|
|
|